perf(gdn): optimize post-conv and causal-conv kernels - #155

Reviewed on GB10 (sm_121a, full production build: CUTLASS + FA2 + vendored Triton-AOT). The structure of this PR is exactly right — committed spikes with upstream anchors, two independently selectable default-off arms, and a retained falsification arm. Most of the red CI is staleness. But there is one real blocker, and it is in the new work.

Blocker: a 0-ulp equivalence regression that main does not have

TEST CASE: CUDA causal_conv1d_fwd register kernel (VT_CONV_REG) matches tiled 0-ulp
tests/vt/test_ops_gdn.cpp:726: ERROR: CHECK( bad == 0 ) is NOT correct!
  values: CHECK( 2661 == 0 )
  logged: c := 1024,  k := 4,  cb.in := 0,  cb.out := 0,  row_padding := 0

Side by side, same box, same build flags, same command:

c=1024, k=4 is precisely the shape VT_CONV_CHANNEL_TILE specialises, and 2661 mismatching elements is not a rounding tail — it is a wrong result, at default settings, on a test that asserts bit equality. Note this fires with the arms unset, so it is not confined to the opt-in path.

Worth checking whether the specialisation changed what the "tiled" reference computes for k=4, rather than only what the register kernel computes — if the reference moved, the test is comparing two new things and the 0-ulp claim in the spike no longer holds.

What I verified, so you don't have to re-do it

Rebasing onto main clears three of the four red checks by itself:

• device-leakage — not your bug. Your branch predates 1f3b7148, which replaced the raw queue.device.type == kCUDA test in QueueSupportsAsyncInputCombine with the Backend::SupportsAsyncSampledTokenReadback() capability. Rebased, the DSR bucket is clean.
• pr-size — errors with base must be an ancestor of head, pure staleness. Passes after rebase.
• agent-record — green on current main.

And the default-off contract holds, which is the important safety property:

default (arms unset)        27B 235/235   35B 315/315   (SACRED)
VT_GDN_POSTCONV_TOKEN_TILE=1  27B 235/235
VT_CONV_CHANNEL_TILE=1        27B 235/235
test_gdn_prefill_conv         88/88

So both arms are token-safe on the 27B gate; the problem is confined to the conv equivalence test above.

Still owed after that

• doc-checkpoint is per-commit: commits 66087699 and the final record commit change .agents/benchmark-record.md without touching .agents/NOW.md. Both need the NOW row in the same commit.
• STATUS ratchet slack — test_the_live_page_keeps_the_character_ratchet_tight wants slack <= 25; re-pin chars to the measured value in the same change.

Heads-up for the rebase: main rewrote AGENTS.md and deleted the structured state record (.agents/state.csv, state-events/, state-index/), so drop any edits to those — narrative lives in the commit message now. I hit a conflict there myself and briefly re-added a 7k-line archived blob before catching it.

I haven't pushed the rebase or touched the code — findings go back to you rather than getting repaired in review. Fix the conv equivalence and the two doc gates and I'll re-run this whole set and merge.

Merged, with two fixes applied during landing and one new issue filed. Thanks — the kernels themselves reviewed clean: no OOB index, no shared-memory overrun, no divergent barrier, no missing tail guard, and no launch-config assumption the launcher doesn't guarantee. I also verified the token-tile reduction-identity claim bitwise: the (q0²+q2²)+(q1²+q3²) fold really is the shipped 128-lane tree's first two levels for the lane + item*32 mapping — 0 of 20,000 random f32 rows differ. And the portable-header suite is genuinely strong: 9 cases / 88 assertions green, with 8 of 8 planted mutations caught.

The one thing I changed in your tests

RunGdnPostConvTokenTileCase could not catch the defect you had to fix.

Your own spec records that the first warp-reduction ordering you tried — summing the four lane-owned squares sequentially — changed production tokens (83fcdc45… → 1d496ff0…) and was rejected for exactly that. I re-created that rejected arithmetic and pushed it through the bf16 store the test compares on:

• 0 of 11,160 rows differ
• 0 of ~1.4M elements differ

The f32 sums do differ (3,580 of 20,000 rows) — but 1/sqrtf moves the result by about 1 ulp f32, and __float2bfloat16 rounds it away. bf16 keeps 8 mantissa bits, so a bf16 CHECK(q1 == q0) is a tolerance gate wearing an exactness costume. It was satisfied by an implementation you already knew was wrong; only your manual e2e token-SHA on sm_120 caught it, and that's neither in CI nor reachable by a reviewer.

Fix applied: the case now takes a DType qkv and sweeps {f32, bf16}, f32 first — the same shape your sibling RunGdnPostConvSplitByteExactCase already uses. With an f32 q_out the mutant fails on 3,580/20,000 rows.

This is worth internalising beyond this PR: whenever a test guards a floating-point reduction order, it needs an F32 output arm. Same trap hides the Tgate = __nv_bfloat16 instantiation, which the case still never reaches because dpacked_ba is f32-only.

New issue #305 — a pre-existing race, not yours

While reading the exact-chunk mapping I found that only chunk 0 reads the initial conv_state (v = srow[width + ti], reachable only when token_offset < width) while only the last chunk writes the final one (srow[j] = v, under token_end == t_len). Those are different, unordered blocks, so they race whenever has_initial_state[s] is set and t_len > kConvExactM. I confirmed both sites on origin/main independently — it's default-ON (VT_CONV_REG + exact chunks) and predates this row, so it got its own issue rather than a silent fix.

Upstream doesn't have this shape: causal_conv1d.py:147-150 keeps the prior-state read and the tl.store in the same Triton program with a debug_barrier() between, and stores to a separate output coordinate.

Related: your channel-tile spec said the accepted arm-2 kernel "preloads both stripes before processing either" as the fix for the stripe-overwrite failure. I corrected that to say it narrows the window rather than closing it — the arm's correctness rests on the initial-state read happening at instruction ~0, not on an ordering guarantee. Your note that a first serial-stripe arm failed the matrix for this reason is actually good evidence the window is observable on that hardware.

Smaller things done while landing

• Your red agent-record check was just the stale docs/STATUS.md character ratchet — the branch shrank the page 137 chars without lowering STATUS_RATCHET["chars"]. Re-pinned to the measured value.
• docs/BENCHMARKS.md quoted a 233.955 ms baseline against the 219.506 ms arm-1 figure, which gives 6.18%, not the 6.44% stated everywhere else — 219.506 was measured against 234.605 in the same run. Now quotes the same-run basis and says so.
• Linked issue RTX 5070 Ti: close Qwen3.5-4B TTFT, TPOT, and VRAM gaps vs vLLM #206 in the roadmap issue table and both specs; it was in neither.
• Conflicts: benchmark-record.md union-appended (it's genuinely append-only), NOW.md rebuilt from main with only your three scoped edits reapplied. I deliberately did not carry your flock /tmp/gpu GPU-lock bullet or the operator-protocol rewording — main is newer on both, and the former contradicts the local-ai-worker parking convention.

One honest limit: the maintainer box has no GPU and no nvcc, so no CUDA test in this row was executed by me. The portable-header results above were run for real; the CUDA-side claims are host emulation over the same index space plus bitwise arithmetic replay. The modified test compiles clean and skips without CUDA — it still owes a real GPU run on your 5070 Ti, and that's the one thing I'd ask you to confirm.